
\chapter{Introduction}

This thesis investigates the feasibility of using a type-safe,
high-level, garbage-collected language for bare-metal programs
on a multi-core SOC. We hypothesize that the operating system
provides redundant and costly isolation to a HLL program running in userspace.
This can reduce execution speed and increase latency to the point where
an embedded programmer is forced to use C and lose the benefits of a HLL.
By running the high-level code directly on bare-metal, the program
can have memory-safety and good concurrency support, but also higher
performance than in userspace.

\section{Motivation}

Modern embedded systems are composed of multi-core SOCs that require
careful thought about concurrency. C is the
most commonly used language to program such low level systems because
it is simple and expressive, but it is
a double-edged sword. Low-level code written in C can more easily and
directly interface with hardware, but it can also be plagued with
difficult bugs, especially concurrency-related bugs and memory bugs like
use-after-free.

Concurrent, high-level user space programs that do not directly interface with
hardware, on the other hand, are usually written in a
high-level language, such as Rust or Go, which abstracts concurrency
and provides memory safety. Rust, Go, and other High Level Languages (HLL's)
will usually ensure that there is never an out of bounds error,
use-after-free error, or unsafe cast. HLL's can also provide native concurrency
support through primitives like channels. The downsides of HLL's are that those
nice features come at a cost of garbage collection and many runtime checks.
Despite the shortcomings, HLL's are still preferred to C programs because fast,
modern computers can neutralize the performance cost. Now that embedded devices are also very fast,
the possibility of using a HLL on a performant embedded system is attractive.

Embedded programmers are often drawn towards using Linux for their work
because then they can write their embedded program in user space with a
high level language in order to avoid the difficulty and poor concurrency
support of C. Popular platforms that use this paradigm include
the Raspi \cite{raspi} and Beaglebone \cite{beaglebone}.
However, embedded programs that run in user space suffer
from significant event latency because of OS isolation mechanisms that exist primarily
for buggy C programs. Memory safe programs written in a HLL do not need to run
in different address spaces and they already ensure that invalid pointers will not
be dereferenced, so the OS does not need to waste more CPU time redundantly ensuring
these properties. Unfortunately, the OS has no way to disable its isolation mechanisms
for a single program, so embedded programmers who want to use a HLL must accept the unnecessary
performance penalty.

There are ongoing efforts to bring high-level languages to desktop
operating system kernels and also single-core microcontrollers, but
there is no known system which provides a high-level language environment for
multi-core SOCs. Singularity \cite{singularity} and Biscuit \cite{biscuit} are desktop
operating system kernels, written in Sing\# and Go, which focus on
hosting user-space programs. Copper \cite{copper} and MicroPython \cite{micropython}
are small embedded tool kits, written in Rust and Python, which aim
to provide a high-level programming environment for single-core
microcontrollers. Multi-core SOCs have, so far, been left out of the
picture.

\section{GERT}

This thesis presents a new embedded toolkit, the Golang Embedded
RunTime (GERT), which is specifically intended for concurrent, bare-metal embedded applications.
GERT is a modified version of the Go runtime which can boot on a bare-metal ARMv7a system and execute Go code.
With GERT, programmers can write embedded programs in Go and run them on multi-core bare-metal hardware.
The Go language, instead of the operating system, provides safety and concurrency abstraction.

\section{Outline}
Below is an outline of this thesis.
\begin{itemize}
  \item Chapter 2 explains why Go was chosen for GERT and also the basic intuition behind the Go runtime implementation
  \item Chapter 3 presents the core work of this thesis, or how the runtime was modified to work on bare metal
  \item Chapter 4 shows how to use GERT, an essential aspect of any toolkit
  \item Chapter 5 evaluates GERT on embedded benchmarks and also two embedded case studies
  \item Chapter 6 concludes this thesis with a review of the results and their implications
\end{itemize}
